Technical Q&A TB43
Drag Manager: Promising and Tracking


Q: Well, I'm losing it. DTSers are supposed to become omniscient and, therefore, never need to ask questions once they leave, but I guess I didn't stay long enough.

We all know how much fun it is to debug Drag Manager problems, and this one is no exception. I'm calling GetFlavorFlags to see if a flavor I want exists, and, sure enough, it does. Later (or even right away as a debugging check) I call GetFlavorDataSize or GetFlavorData and I get the error code -1854. Not in every situation, but in very repeatable cases. If my app is the source of the data as well as the target it always fails. Drag data is always set by passing nil for the data pointer to AddDragItemFlavor, but my DragSendDataProc doesn't seem to get called. Apparently, Drag Manager detects the error condition before ever calling me.

A: My guess is that you are attempting to obtain flavor data during your drag tracking handler. When the data is promised ("Drag data is always set by passing nil for the data pointer to AddDragItemFlavor"), Drag Manager does not call the sender's SendDataProc. Why?

Well, the problem has to do with drop locations and caching. Once the data has been obtained, it is cached in the DragReference. Subsequent requests return the size or data from the cache, and the SendDataProc is not called. Some drag senders may wish to provide different data on a drop-location-by-drop-location basis. Allowing the data to be cached in a drag-tracking handler would prevent them from doing this.

If you want to ask for the data inside your tracking handler, you'll have to make sure the sender does not promise the data you care about. Since that is not practical when you are interacting with apps you can't revise, what you really have to do is restructure your code so that it does not need the data during its tracking handler.

Further Reference:

Drag Manager documentation

[Dec 22 1998]


Developer Documentation | Technical Notes | Development Kits | Sample Code